Post

Replies

Boosts

Views

Activity

Reply to Importing Data into SwiftData in the Background Using ModelActor and @Query
I'm writing to express my frustration and disbelief that this critical bug is still present in production as of 2026. We just completed a major refactoring effort, migrating our application from iCloud-based static file storage to SwiftData with CloudKit sync. During this migration, we encountered this exact issue and was stunned to discover it was already documented in 2024. Here one of several specific scenarios: Logbook view structure: @​Bindable var logbook: ​Logbook (where Logbook is a @​Model class) The logbook​.flights relationship array is not observed - changes to the array don't trigger view updates Attempted workaround using @​Query var flights: [​Flight] - still not observed This affects one of our primary user-facing views (flight logbook table) Why the suggested workaround doesn't work: The proposed solution of triggering refreshes on model​Context​.did​Save notifications is impractical for real-world applications: • Context saves can occur multiple times throughout the app's lifecycle • Frequent UI refreshes cause jarring user experience • Table selections are lost on every refresh • State management becomes a nightmare when you can't trust the observation system This is unacceptable: • It's been two years since this was first reported • SwiftData was marketed as a production-ready replacement for Core Data • Basic observation of to-many relationships should be fundamental functionality • The workarounds compromise UX and require architectural gymnastics We need either: A proper fix for relationship observation Official guidance on the correct architectural pattern Acknowledgment that either SwiftData or @Query aren't ready for production use with CloudKit sync This bug is blocking legitimate use cases and forcing developers to choose between broken observation or constant, disruptive UI refreshes. When can we expect a real solution?
3w
Reply to Importing Data into SwiftData in the Background Using ModelActor and @Query
I'm writing to express my frustration and disbelief that this critical bug is still present in production as of 2026. We just completed a major refactoring effort, migrating our application from iCloud-based static file storage to SwiftData with CloudKit sync. During this migration, we encountered this exact issue and was stunned to discover it was already documented in 2024. Here one of several specific scenarios: Logbook view structure: @​Bindable var logbook: ​Logbook (where Logbook is a @​Model class) The logbook​.flights relationship array is not observed - changes to the array don't trigger view updates Attempted workaround using @​Query var flights: [​Flight] - still not observed This affects one of our primary user-facing views (flight logbook table) Why the suggested workaround doesn't work: The proposed solution of triggering refreshes on model​Context​.did​Save notifications is impractical for real-world applications: • Context saves can occur multiple times throughout the app's lifecycle • Frequent UI refreshes cause jarring user experience • Table selections are lost on every refresh • State management becomes a nightmare when you can't trust the observation system This is unacceptable: • It's been two years since this was first reported • SwiftData was marketed as a production-ready replacement for Core Data • Basic observation of to-many relationships should be fundamental functionality • The workarounds compromise UX and require architectural gymnastics We need either: A proper fix for relationship observation Official guidance on the correct architectural pattern Acknowledgment that either SwiftData or @Query aren't ready for production use with CloudKit sync This bug is blocking legitimate use cases and forcing developers to choose between broken observation or constant, disruptive UI refreshes. When can we expect a real solution?
Replies
Boosts
Views
Activity
3w
Reply to Catalyst & Audio Units: getting plugin dimensions right
So here we have the proof Apple engineers are liars. Auv3 is a joke. Many posts in this forum without answer. Not a single audio unit in the market calls select configuration. Not a single one. Then you ask why are we using Juice. Fuck off.
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
Nov ’24